package com.zjl.redis.第16章_分布式锁;

import cn.hutool.core.lang.UUID;
import io.lettuce.core.api.sync.RedisCommands;
import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.config.Config;

import java.math.BigDecimal;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.LinkedBlockingDeque;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

/**
 * 使用Redis的分布式锁
 * Redis的分布式锁模式
 * 在不同进程必须以方式使用共享资源的许多环境中，分布式锁是一个非常有用的原语。
 * 有许多库和博客文章描述了如何使用Redis实现DLM (分布式锁管理器)，但每个库都使用不同的方法,
 * 并且许多库使用简单的方法，与稍微复杂的方法相比,保证较低设计。
 * 本页描述了一个更规范的算法来使用Redis实现分布式锁。
 * 我们提出了一种称为 Redlock 的算法, 实现了我们认为比普通单实例方法更安全的DLM。
 * 我们希望社区对其进行分析、提供反馈,并将其用作实施或更复杂或替代设计的起点。
 *
 * 为什么基于故障转移的实施是不够的？********************************************
 * 为了理解我们想要改进的地方，让我们分析一下大多数基于 Redis的分布式锁库的现状。
 * 使用Redis锁定资源的最简单方法是在实例中创建一个键。
 * 使用Redis的过期功能，密钥通常是在有限的生存时间内创建的，因此最终它会被释放(我们列表中的属性2)。
 * 当客户端需要释放资源时，它会删除密钥。
 *
 * 表面上这很好，但有一个问题:这是我们架构中的单点故障。如果Redis master宕机了怎么办?
 * 好吧，让我们添加一个副本!如果主人不可用，请使用它。不幸的是，这是不可行的。
 * 这样做我们无法实现互斥的安全属性,因为Redis复制是异步的。
 *
 * 此模型存在竞争条件:
 * 1.Client A获取 master 中的锁。
 * 2.在对密钥的写入传输到副本之前,主服务器崩溃了。
 * 3.副本被提升为主。
 * 4.客户端B获取对同一资源A已持有锁的锁。违反安全规定!
 *
 *  有时在特殊情况下，例如在故障期间，多个客户端可以同时持有锁是完全没问题的。
 *  如果是这种情况，您可以使用基于复制的解决方案。否则，我们建议实施本文档中描述的解决方案。
 *
 */
public class C1_为什么引入Redisson实现分布式锁 {
}
